IBIS Macromodel Task Group Meeting date: 21 March 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad noted that he had cleaned up the Pending BIRDs sections of the agenda email by removing BIRDs that had been approved (BIRDs 147.6 and 188.1) and removing a duplicate entry for BIRD 158.3. - Arpad noted that he had forgotten to renumber the list of agenda items in this week's agenda email. - Walter noted that he had prepared a new BIRD proposal to address the reference terminal issue. He asked that we review it during the meeting. He noted that it was related to the ongoing referencing discussion Bob R. and Radek had been having (item #12 New BIRDs from the Editorial Task Group). Mike LaBonte noted that since the Editorial Task Group had reconvened this item might move to a lesser priority in ATM. Radek said that this issue was technical in nature and slightly more than just editorial, and he suggested it should maintain its place on the ATM agenda. ------------- Review of ARs: - Michael Mirmak to submit BIRD 187.3 to the Open Forum. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Bob R.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow BIRD: - Arpad: Fangyi said he could not attend today. - Vladimir and I have sent him some comments on his proposal. - A discussion is taking place. - We are reviewing the convolution equations, which are now utilizing the notation suggested by Walter and Todd. - Anyone else feel free to comment on the proposal. - Ambrish: Is the version from Jan 17th on the ATM website the latest? - Arpad: Yes. BIRD 158.4: - Walter: I think Radek and I were waiting for Ambrish's review. - Ambrish: Where in the specification will this BIRD actually go? - Radek: In the AMI section. - Ambrish: A new chapter? - Bob R.: A new section in the AMI Reserved Parameters. - Ambrish: Is there going to be cross referencing with this BIRD in the analog buffer and [External Model] sections? - Will there be a recommendation that the model maker should provide both methods ([External Model] and BIRD 158) or just one? - Walter: Model makers have requested that they do the Touchstone this way (BIRD 158) instead of using the [External Model]. - Nothing will force the model maker to use BIRD 158. - Ambrish: We have some history for suggesting alternatives, C_comp is used if C_comp_xxx isn't supported, for example. - Radek: Based on your earlier comments, we already added the "in lieu of" language. It explicitly states that this is a replacement for what is in [Model]. - That statement can be expanded to say that if the model maker wants to have the same functionality in both there is nothing wrong with that. - Ambrish: Something to the effect that this BIRD 158 approach is only for AMI simulation. - The user should not expect other simulation types to utilize this. - Radek: That can be added. - We should probably clarify the general approach for this one. - Ambrish: If both BIRD 158 and [External Model] are available, which one takes precedence? - Radek: That precedence is already stated. BIRD 158 replaces the contents of [Model]. [External Model] is part of the [Model]. - Bob R.: I support making this a clean separation. - You can't use BIRD 158 as a quick and dirty way to introduce a Touchstone model in regular applications. BIRD 158 is only for AMI applications. - I would explicitly add a new statement that if you have an [Algorithmic Model] then you can use the Ts4file to replace everything in [Model] for an AMI simulation per BIRD 158. - Radek: That is the intent. - Ambrish: Should there be any discussion regarding mixing Tx or Rx models that use BIRD 158 or don't? - Radek/Walter: No, there is no restriction. They can be mixed and matched. - Ambrish: Did we clarify how package models will be handled? - Radek: There were some good suggestions by Bob Miller. - We can at least indicate the boundary of what is being included in the Ts4file data. - Whether we have to have the package model in an additional Touchstone file is unclear at this moment if we leave it entirely to the user. - Ambrish: I'll distribute this for further comment. - Radek: The current working version is still draft 2 (Feb 28th ATM archives). We know there are plenty of editorial issues to deal with if we decide to move forward with this proposal. - Walter: I think consensus is that we incorporate the discussions from last week into a new draft. - I think it would be clear and complete at that point. - I think it's worthwhile for Radek to do it, and I will help. - Radek: Okay, we can work on it. - Arpad: There seems to be some urgency to this given discussions of what will go into the next revision of the spec. Walter's new BIRD proposal (reference terminal): - Walter: [sharing the proposal] - This is another attempt to address the voltage referencing issue. - IBIS defines the derivation of "IBIS Data" consisting of I-V, V-T, ISSO, and threshold voltages for a device under test (DUT). - IBIS data assumes the buffer rail terminals are supplied specific rail voltages prescribed by the [Voltage Range] or [* Reference] keywords. - IBIS has assumed the test fixture reference was "ground", which was at 0.0V relative to simulator "node 0". - That assumption was made when data rates were 20 Meg. Now they are 56 Gig. - "Ground" is no longer a valid concept. Voltages at I/O buffer terminals must be measured relative to a local signal reference. - The only possible local signal references in an I/O buffer are the rail terminals of the buffer. - Discussion: Walter asked if everyone agreed with the "definition of the issue" statements. Bob R. disagreed and said that the construction of the I/V tables remains relative to simulator reference "node 0". He said that high speed simulation involved a different type of reference, which was where a reference terminal concept comes in. He said the two should not be mixed. Walter disagreed and said the two had to be mixed. He said the measurements of the DUT were made relative to the test fixture reference node ("node 0"), but that node (with rare exceptions) was usually one of the terminals of the device. Michael M. also expressed concern at Bob's assertion that node 0 was somehow smuggled into the I/V tables. Walter said that at DUT measurement time "node 0" was simply the point where the black probe of the volt meter was placed. He said this test fixture reference should be as close as possible to the I/O buffer itself. Bob said this was a key misunderstanding, but Walter asked that we defer further discussion on this point until after the full review. - Walter: [continuing the review] - The BIRD introduces a new optional sub-parameter Reference_terminal. - It specifies the rail reference terminal that is used to make voltage measurements at all the terminals of the I/O buffer (except for control terminals like stimulus, enable, etc., which are always relative to node 0). - The BIRD also defines which rail terminal shall serve as the reference when Reference_terminal is not specified. - The BIRD does not attempt to define how voltage measurements should be compared to measurement threshold values in the IBIS [Model] when the voltages measured at the rail terminals relative to the Reference_terminal are not the same as the DC values given in the [* Reference]. - Reference_Terminal - Required: No - Value shall be one of the following (adopting the [Pin Mapping] names): - pulldown_ref - pullup_ref - gnd_clamp_ref - power_clamp_ref - ext_ref - pulldown_ref and pullup_ref are illegal for Input models - Discussion: Bob noted the sentence stating that ext_ref was illegal unless the [Model] contained an [External Model] was incorrect. He said they were entirely independent concepts. Radek agreed. Walter removed the offending sentence from the draft. - Walter: [continuing the review] - If there is an [External Model], the Reference_terminal must be one of the ports of the [External Model]. - The map between Reference_terminal allowed values and [External Model] port names is listed here. - If you say the Reference_terminal is power_clamp_ref, for example, then your [External Model] must have A_pcref. - The Voltage at an I/O or rail terminal shall be: Voltage at terminal = V(terminal, Reference_terminal) + the value of the [* Reference] keyword corresponding to the Reference_terminal. - If no Reference_terminal is specified: - All [* Reference] keywords that are zero have their associated *_ref terminals shorted together. Any one of these terminals can then be used as the Reference_terminal. - If none of the [* Reference] keywords are zero, then the EDA tool can choose any of the corresponding terminals as the Reference_terminal. - On page 72, change: The absolute GND is the reference for the V_fixture voltage and the package model equivalent network. It can also serve as a reference for C_comp, unless C_comp is optionally split into component attached to the other reference voltages. to: The Reference_terminal shall serve as a reference for C_comp, unless C_comp is optionally split into reference terminals. - Bob: The last section now mixes extraction and simulation. - We had assumed in the notes on derivation that we zero out all packages and have perfect supplies. - So it's equivalent to C_comp going to ground. - C_comp includes by definition all the capacitance to all the exposed terminals. - So I have a problem saying C_comp now has to go to any terminal listed as 0 in its [* Reference]. We would now be arbitrarily deciding that C_comp is really C_comp_xxx to a particular terminal. - We could be redefining things in a way that isn't consistent with extraction. - I do like this idea of a sub-parameter. - I think we should provide a list of suggestions but not new rules. - Discussion: Walter said the fundamental point is that you can only make measurements on a buffer pad (especially the I/O pad) relative to the rail terminals of that buffer. Only the rail terminals and the I/O pad are available to the actual measurement probe or the simulator. Bob disagreed and said with a simulation you're free to measure your voltages relative to any node. Walter disagreed and asked Bob to draft an email to ATM containing his concerns. Walter said he would send his proposal to Mike LaBonte for posting. - Radek: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter and Radek to work on a draft 3 of BIRD 158.4. AR: Walter send a draft 1 of his Reference_terminal proposal to Mike LaBonte for posting. AR: Bob Ross to email ATM with his concerns about the Reference_terminal proposal. ------------- Next meeting: 28 March 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives